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IMAP4 COMPATIBILITY WITH IMAP2BIS 
Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Introduction 


The Internet Message Access Protocol (IMAP) has been through several 
revisions and variants in its 10-year history. Many of these are 
either extinct or extremely rare; in particular, several undocumented 
variants and the variants described in RFC 1064, RFC 1176, and RFC 
1203 fall into this category. 


One variant, IMAP2bis, is at the time of this writing very common and 
has been widely distributed with the Pine mailer. Unfortunately, 
there is no definite document describing IMAP2bis. This document is 
intended to be read along with RFC 1176 and the most recent IMAP4 
specification (RFC 2060) to assist implementors in creating an IMAP4 
implementation to interoperate with implementations that conform to 
earlier specifications. Nothing in this document is required by the 
IMAP4 specification; implementors must decide for themselves whether 
they want their implementation to fail if it encounters old software. 


At the time of this writing, IMAP4 has been updated from the version 
described in RFC 1730. An implementor who wishes to interoperate 
with both RFC 1730 and RFC 2060 should refer to both documents. 


This information is not complete; it reflects current knowledge of 
server and client implementations as well as "folklore" acquired in 
the evolution of the protocol. It is NOT a description of how to 
interoperate with all variants of IMAP, but rather with the old 
variant that is most likely to be encountered. For detailed 
information on interoperating with other old variants, refer to RFC 
1732. 


IMAP4 client interoperability with IMAP2bis servers 


A quick way to check whether a server implementation supports the 
IMAP4 specification is to try the CAPABILITY command. An OK response 
will indicate which variant(s) of IMAP4 are supported by the server. 
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If the client does not find any of its known variant in the response, 
it should treat the server as IMAP2bis. A BAD response indicates an 
IMAP2bis or older server. 


Most IMAP4 facilities are in IMAP2bis. The following exceptions 
exist: 


CAPABILITY command 
The absense of this command indicates IMAP2bis (or older). 


AUTHENTICATE command. 
Use the LOGIN command. 


LSUB, SUBSCRIBE, and UNSUBSCRIBE commands 
No direct functional equivalent. IMAP2bis had a concept 
called "bboards" which is not in IMAP4. RFC 1176 supported 
these with the BBOARD and FIND BBOARDS commands. IMAP2bis 
augmented these with the FIND ALL.BBOARDS, SUBSCRIBE BBOARD, 
and UNSUBSCRIBE BBOARD commands. It is recommended that 
none of these commands be implemented in new software, 
including servers that support old clients. 


LIST command 
Use the command FIND ALL.MAILBOXES, which has a similar syn- 
tax and response to the FIND MAILBOXES command described in 
RFC 1176. The FIND MAILBOXES command is unlikely to produce 
useful information. 


* in a sequence 
Use the number of messages in the mailbox from the EXISTS 
unsolicited response. 


SEARCH extensions (character set, additional criteria) 
Reformulate the search request using only the RFC 1176 syn- 
tax. This may entail doing multiple searches to achieve the 
desired results. 


BODYSTRUCTURE fetch data item 
Use the non-extensible BODY data item. 


body sections HEADER, TEXT, MIME, HEADER.FIELDS, HEADER.FIELDS.NOT 
Use body section numbers only. 


BODY .PEEK [section] 
Use BODY[section] and manually clear the \Seen flag as 
necessary. 
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FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items 
Use the corresponding non-SILENT versions and ignore the 
untagged FETCH responses which come back. 


UID fetch data item and the UID commands 
No functional equivalent. 


CLOSE command 
No functional equivalent. 


In IMAP2bis, the TRYCREATE special information token is sent as a 
separate unsolicited OK response instead of inside the NO response. 


IMAP2bis is ambiguous about whether or not flags or internal dates 
are preserved on COPY. It is impossible to know what behavior is 
supported by the server. 


IMAP4 server interoperability with IMAP2bis clients 


The only interoperability problem between an IMAP4 server anda 
well-written IMAP2bis client is an incompatibility with the use of 
"\" in quoted strings. This is best avoided by using literals 
instead of quoted strings if "\" or <"> is embedded in the string. 


Security Considerations 

Security issues are not discussed in this memo. 
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